A conventional method for shared resource release notification includes polling of software semaphores. In such a context, each software semaphore is a globally available memory location used as part of a semaphore set or a semaphore clear operation by all participating masters. By checking a state of a semaphore before attempting to use an associated resource, a master is able to guarantee exclusive access to the resource.
Some existing processors check a semaphore using a SWAP instruction that exchanges a value of an internal register with a value in an external memory location pointed to by one of the registers as an atomic operation. The value in the internal register is first set to indicate the semaphore is in use and then the SWAP instruction is executed. Next, the memory contents, which now reside in the register, are checked to see if the semaphore was already set (i.e., in use) or if the semaphore was cleared (i.e., not used). If the semaphore was cleared, the program obtains ownership of the resource since the SWAP instruction exchanged the cleared value with the set value. If the semaphore is already set, then the value in the memory location is left unchanged and the program tries to obtain ownership at a later time. However, the time just spent querying the state of the semaphore is wasted.
Software semaphores are typically implemented in a shared memory. The semaphores are accessed using a mechanism such as the one described above or in a manner that guarantees exclusive or atomic operation to read-modify-write the semaphore location. A problem with the use of software semaphores is that the associated resources are not used very efficiently. The use of a software semaphore means that a processor first runs a piece of code that reads a semaphore flag to determine whether the resource is available or not. Since the resource is being shared, a possibility exists that at the time the semaphore is checked, the semaphore is in a state that indicates the resource is in use. The master that wants to acquire the resource then idles or performs some other function before returning to recheck the state of the semaphore. Since checking the semaphore state may happen many times before the semaphore is actually set, a lot of time is potentially wasted.
In the time between checks, another possibility exists that the resource could have become available momentarily then reserved by another master. Random checking is also not a very equitable way to share the resource since a likely-hood of gaining access to the resource is directly related to how often a check is performed. At the same time, since masters are not likely to check the state of the resource as soon as it becomes available, the resource itself may become idle in-between uses and so not efficiently used.
Conventional semaphores do not convey any information other than an availability of a resource. Therefore, other software mechanisms are often used to pass messages between different tasks or processors. The software would be designed to allocate and maintain the messages in a portion of a general purpose memory located some where in the system. Each different type of message would allocate additional memory. The software would also be responsible for setting a status bit and triggering an associated interrupt via some other mechanism.